The past month or so I’ve reviewed a lot of code, and one issue is cropping up all the time: too much use of @property

Suppose we have the class AlbumViewController that extends UIViewController, and is used to display information about a music album. In the view, we want to display a title, and some artwork. So we make our storyboard, and drop a UILabel and UIImageView into a view controller of the class AlbumViewController. Now, how do we hook them up? We’ve got really four alternatives:

1. Instance variables in the interface declaration

1. Properties in the interface declaration

1. Hidden properties

1. Instance variables in the implementation

Objective C, in Apple’s incarnation, doesn’t have any sense of private, protected and public variables and methods: everything is public.

Instance variables are accessible only to the class, and its subclasses.

Properties are accessible from any object that has a reference to the object that exposes these properties. This is the main reason for having properties. The second reason is if you want to have the getting or setting of a property to have some side-effects.

So, in the example above, if we choose properties, hidden or explicitly public, we invite other objects to manipulate these properties directly. Thus we need to inspect our interface: does it make sense to expose the UILabel and UIImageView directly? Can the class AlbumViewController handle that other objects will manipulate these views? Probably not.

Properties that would make sense, from a class interface perspective, would be setting the album title and artwork. Then you can keep the presentation of these as an implementation detail:

This way you have nice encapsulation, and thus make your class easier to use for the next person coming in to your project, or your self next week.

My issue with alternative #2 and #3 is that they are really the same: they expose the properties to the world, even though alternative #3 tries to obscure it a bit. If you write any kind of dynamic code using just the tiniest bit of class introspection, the methods will offer their service straight away. So unless your interface is to expose these properties, don’t use that. The only thing you’ve gotten extra out of this is having to ask people not to use your properties, and a slightly added cost to accessing your instance variables.

Alternative #1 is good if you want the instance variables to be available to subclasses, and make it clear that these should be considered. Again, there’s not all that much difference between this and alternative #4, but #1 is more explicit and readable, so it’s a great place if you expect it to be useful for subclasses.

Alternative #4 is my preference for everything that is just something I need to get my implementation of this class done. And I really think it should be yours as well, and is what should be taught in basic iOS training. Unfortunately, surprisingly many go for alternative #3, cluttering the interface with lots and lots of “hidden” properties, that aren’t hidden at all, especially not at runtime.

So to sum up: think about your interface and what you want to expose to the world. Expose only this, keep everything else as an implementation detail, unless you expect the class to be subclassed. Then you can expose some of the instance variables in your interface as well.

As a final PS, we’re not doing the compiler any favour going into these details, it will get its work done anyhow. But this is so that we can keep a clear interface when communicating with other developers coming into the project, using the project, and to your future self that is working on the project.

Now that I’ve posted my view, I would love to hear your opinions, especially because I would love to hear some good arguments in favour of alternative #3.

Wow, the libpd guys make it possible to put Pure Data patches in your iPhone app. I’m definitely going to make an app based on this, if nothing more then just for the heck of it. Time to brush up on my PD skills, I’ve been using Max/MSP for too long See the article

I’ve been having some issues using the

- (NSManagedObjectModel *)managedObjectModel

function. First it didn't load well, but Marcus Zarra helped me out there on Stack Overflow. The funny thing was of course that up until now, it'd worked great on the phone but not the simulator. That solved, it stopped working on my phone, but I was working so much in the simulator I didn't pay a lot of attention to it.

Anyway, today I wanted to have that figured out, and I came across this great post by Jeff Lamarche, and while it didn't explain to me why I had multiple versions on my phone but not my simulator, even after I had wiped the application and application data completely, it allowed me to load the correct model. So now everything is running smoothly and the app is coming along great.

If you've been having the same kinds of issues, I hope these links help you as much as they did me.

I’m making OSC controllers for the iPhone, and I just sat down to check out the competition. Some projects, like TouchOSC and OSCemote are for pay. However, they are both out-competed on features and looks by Mrmr by Eric Redlinger. His version is soo much closer to what I have in mind, implements all the features by the two others and is free. That’s a mighty good package you have there, Eric.

Status on my week is that I’m not to fond of doing the web-bit, so I’m not giving myself any exposure either. The functionality is coming nicely together for the apps, and I’m starting to get a couple of beta-testers, but I’ll probably spend some time finding a couple more. Right now I really need a graphics artist and someone who enjoys doing CSS

Jay, revived a project from back in April (Lighting Matrix for Max) from back when the iPhone SDK was NDA and only beta #3 was out. Well, for my first day of serious iPhone dev, I revived it, made it run with the current version, ripped out the Max/MSP part and inserted OSC instead. Good fun